One request. Eight checkpoints. One question each.
Nobody in the path decides everything. Every layer answers exactly one narrow question, then hands the request to the next layer. That's the whole trick behind systems that scale.
the mental model
Think of it as a parcel, not a request
A parcel moving through customs doesn't get fully inspected at one desk. Each checkpoint checks one thing — passport, ticket, baggage, gate — and passes it on. A web request works the same way. DNS never looks at HTTP. The Layer 4 balancer never looks at a URL path. The Gateway never picks the pod. No component tries to do the next one's job — and that's exactly what lets each layer scale, fail, and get replaced independently.
the journey · tap to expand
Follow https://api.shop.com/orders/123 hop by hop
Each stop below is a real machine or service. Click one to see exactly what question it asks — and nothing more. The WAF is the new bouncer at the door.
cheat sheet
Every layer, one line each
Layer
Decision it makes — and nothing more
the easiest way to remember it
It's a hospital visit
the question everyone asks
If the API Gateway does everything, what's left for the Load Balancer?
They operate at two completely different altitudes. The LB never sees "business." The Gateway never sees "raw connection."
Load Balancer decides WHO gets the connection. API Gateway decides WHAT happens to the request.
Load Balancer — still doing this
Spreads raw connections across every healthy Gateway instance
Terminates / offloads TLS at scale
Health-checks Gateway instances, pulls dead ones out
Absorbs L3/L4 floods before they reach app infra
Gives you one stable VIP even as Gateway instances scale up/down
API Gateway — only starts here
Authentication & authorization (JWT / OAuth)
Per-user / per-key rate limiting
Request/response transformation
Routing to the correct microservice
Logging, tracing, request aggregation
how to decide
What actually belongs in the API Gateway?
Ask this
If yes →
Does it need to know who the caller is?
Gateway
Does it depend on the URL path, headers, or payload content?
Gateway
Is it identical for every single request, regardless of business meaning? (TLS, health check, raw distribution)
Load Balancer
Does it change per environment (canary %, A/B rules, feature flags)?
Gateway
Would it need to happen even if your app were a static file server?
Load Balancer
deep dive
How L7 content-based routing actually works
Once the L7 balancer can read the HTTP request, it matches it against an ordered rulebook. First rule that matches, wins.
IF Host == "api.shop.com"AND Path startsWith "/orders"→ Order Service PoolIF Host == "api.shop.com"AND Path startsWith "/payments"→ Payment Service PoolIF Header["X-Beta-User"] == "true"→ Canary PoolIF Cookie["session_region"] == "IN"→ Mumbai PoolIF Path == "/static/*"→ CDN / Static PoolDEFAULT→ 404 Pool
This is exactly the mechanism behind canary releases, A/B testing, blue-green deploys, and regional routing — no application code changes, just rulebook changes at the LB.
the diagram, redrawn
Two questions, two different machines
Client
│
│ "How do I reach a Load Balancer?"
│
├──▶ DNS
├──▶ Anycast
├──▶ VIP
└──▶ ECMP
│
▼
Load Balancer
│
│ "Which backend server should handle my request?"
│
├──▶ Server 1
├──▶ Server 2
└──▶ Server 3
Two separate problems, solved by two separate systems — reaching the LB is a routing/DNS problem, picking the server is the LB's own problem.
in short
What's the actual use case for a Layer 4 load balancer?
L4
One job: spread raw TCP/UDP connections across healthy backends — fast — without ever opening the packet to read HTTP. Use it for raw speed, TLS pass-through, or any non-HTTP protocol: databases, gRPC streams, game servers, custom TCP services. It doesn't know a URL path exists.
decision tree
When to use L4 vs L7
What does this traffic actually need?
Need speed?
Use L4
raw connection balancing, no packet inspection
Need intelligence?
Use L7
route by host, path, header, cookie
Need speed and smart routing?
L4 + L7 together
L4 absorbs the flood, L7 does the thinking
where do they actually sit
Nginx and Kubernetes — same journey, different job titles
Nginx isn't one fixed layer. It's a tool that gets deployed to play different roles depending on where you put it. Tap each role below.
quick recall
Flip each card — name the question or the one-liner